The complexity of modern software applications has made the installation, maintenance and support of large software systems difficult and expensive. Increasingly greater skill is required for installing and configuring commercial software systems such as web servers, databases, portals, and messaging and transaction processing systems. Complex software environments such as these pose both administrative and serviceability challenges.
As an administrator of such an environment, it is challenging to keep all of the installed applications on the system up to date with vendor issued patches, because the timing of when to apply a patch depends on when the business environment can tolerate the disruption, not when it is convenient for a particular software vendor. As a result, it is common for customers to be out of synchronization with a software vendor's recommended current version. This problem is compounded when the software system consists of multiple inter-dependent applications, yet the system as a whole must be administered as a unit.
As a service and support organization, it is challenging to fully understand the state of every customer's installed system, because different customers may have slightly different variants of the same system due to differences in the choices and the timing of applying patches and upgrades. As a result, problem diagnosis continues to increase in difficulty as the number of variations of a software system in the field proliferates beyond the capacity of any services and support organization to fully understand the idiosyncrasies of every variant.
Over time, this situation forms a vicious circle. Customers become more conservative in applying new patches because of the risk of moving from a system whose behavior (and idiosyncrasies) is more predictable to one whose behavior is less predictable. This, in turn, makes the customers' platform get further out of synchronization with vendor-recommended and supported versions, resulting in increased service and support costs.
Although a number of techniques exist for simplifying the task of software maintenance, none of them address the serviceability problem that results from a proliferation of unsupported system variants in the field arising from the inability of software vendors and service and support organizations to control the choice or timing of applying customer patches and upgrades. Automated patch installation and self-update mechanisms are examples of techniques that simplify the task of software maintenance. But business-critical systems rarely employ these automated mechanisms as customers generally prefer tighter control over the choice and timing of applying updates. Automation of install and update procedures is therefore not an adequate solution to the serviceability problem.
The installed image of a software system is a focal point of any solution that addresses software installation, maintenance and serviceability issues. An installed image includes the file system layout consisting of executable code and other text or binary artifacts, environment variables (such as registry entries on Windows platforms), and implicit dependencies on items outside of the installed image (such as system libraries and other locally installed applications).
Conventional mechanisms for creating an installed image fall into two categories: an explicit install model and an implicit install model. In the explicit install model, each application is installed individually on every machine on which it will execute. In the implicit install model, applications are installed once on an install machine, and the same installed image is executed everywhere. The implicit install model can be realized in two ways: through image copying or through virtualization.
Image copying refers to the copying of an installed image from the install machine to an execution machine. A common method for doing this is by mounting one or more file systems containing the installed image onto the execution machine. In this scheme, a file server on the install machine and a file system driver (or equivalent logic) on the execution machine cooperate to page the installed image over a network connection.
Image copying is straightforward to implement, but has several limitations. A first limitation is that applications requiring non-file system artifacts (such as environment variables and registry entries) to be initialized prior to execution cannot be installed using this model. Conventional solutions based on image copying via file system mounting address this limitation by ensuring that a special prepare step is executed prior to execution of the application itself, which temporarily initializes the execution machine's environment for the duration of the application's execution. One problem with this approach is that restoration of the original execution machine environment cannot be performed reliably in the event of an application or operating system (OS) crash.
A second limitation of image copying is that the copied image may interfere with existing file system and environment artifacts belonging to normally installed applications on the execution machine. A third limitation of image copying is that multiple variants (e.g. different patch levels of the same application installed image) cannot co-exist simultaneously. Differing installed images must occupy distinct areas of the file system in order to co-exist, which can incur significant storage redundancy due to duplication of the portions of the two images that are identical. Furthermore, if the different installed images need to set conflicting values for environment variables (such as Windows registry entries), only one can operate at any given time.
Virtualization refers to the interception of an application's communication with its underlying runtime platforms such as the OS or a JVM (a virtual machine using Java technology). Virtualization can be used to give an application the illusion that it is running in the context of its install machine, even though it is executing in the (possibly different) context of a host execution machine. Conventional full-system virtualization techniques emulate a hardware machine on which an OS (distinct from that of the host execution machine) can be booted. Full-system virtualization incurs a significant performance penalty, and is primarily intended for testing and porting across different OS platforms. Assuming that installed images are always platform-specific (e.g. a Windows/x86 and a Linux/x86 application will each have a separate platform-specific installed image), then much of the host execution machine's operating system and hardware interfaces can be used directly without virtualization. This selective virtualization approach incurs significantly lower performance overhead than full-system virtualization and is practically indistinguishable from direct execution performance.
FIG. 1 is a block diagram showing the system architecture of a computer system implementing a conventional explicit install model and an implicit install model. FIG. 1 shows an execution machine 100, on which is installed an installed image 102 of a computer program or application, and execution machine 120, on which is installed an installed image 122 of the computer program or application. The installed images 102 and 122 are created via an explicit install step, which writes the full installed image of the application to disk and performs the initialization of the execution machine's environment that is necessary for proper execution of the application. The installed images 102 and 122 of the application are executed on the execution machines 100 and 120, respectively. This configuration adheres to the explicit install model, as explained in greater detail above.
FIG. 1 further shows an install machine 104, on which is installed an installed image 106 of a computer program or application. The execution machines 100 and 120 are linked to the installed image 106 on the install machine 104 and executes the installed image 106. The execution machines 100 and 120 can mount a file system containing the installed image 106 wherein a file server on the install machine 104 and a file system driver (or equivalent logic) on the execution machines 100 and 120 cooperate to page the installed image 106 over a network connection 135 via network 108 or a direct connection 110 and 130, respectively. This configuration adheres to the implicit install model, as explained in greater detail above. It should be noted that although only two execution machines 100 and 120 are shown in FIG. 1, the present invention supports any number of execution machines interacting with an install machine 104 in order to execute an installed image.
Deployment refers to making software accessible to users. Deployment can occur by installation on machines owned by the users, by remote execution in a hosted or utility environment, or some creative compromise between the two. Versioning refers to either or both of: 1) switching between versions of a software asset, either upgrading or “downgrading” as needed, and 2) sorting out the sharing and prerequisite graph of a set of co-resident assets, where different assets may require different versions of a prerequisite. An “asset” refers to the closure of an application and all of its (non-OS) dependencies. E.g., if an application requires an external JVM (not part of the packaged application) for execution, the asset corresponding to that application must include a JVM. Servicing refers to both problem determination and the insertion of fixes and upgrades in a fashion least disruptive to the user.
In a pure hosted or utility approach, the problems discussed above have a commonly-used solution: important software executes on servers. Servers are typically specialized and thus have relatively few conflicts between co-resident assets. Software residing on servers is serviced and upgraded in a planned fashion by skilled personnel. This servicing and upgrading is labor-intensive, but, by aggregating execution in server farms, the hard work can be done once and then replicated across machines.
The hosted solution, however, does not work for all cases. Users often want to be able operate personal machines without continuous network connectivity. Large enterprises continue to demand the security and predictability that comes from controlling their own equipment. Unfortunately, when software is installed on user equipment, upgrading and maintenance becomes more difficult. For example, deployment involves a stop-and-wait install step, version switching is error-prone and version conflicts are common. Further, servicing is extremely labor-intensive because service personnel must spend considerable time understanding the idiosyncrasies of a user's install environment and collecting diagnostic information via an intermediary (the end-user) who lacks the skill to collect it. As a consequence, approaches to this problem have arisen, including auto-installation of software at first use and to auto-upgrading of software. Additionally, approaches to remote problem determination and versioning have arisen.
One approach commonly taken to the versioning problem includes: 1) accurately representing software prerequisite graphs, 2) ensuring satisfaction of dependencies at install time, and 3) imposing requirements on how components are permitted to evolve. If dependency and version information is accurate and the evolution rules strictly followed, there will be a least upper bound on the version of each component required to be maintained in the user machine. This methodology, however, can be error-prone. A complimentary technique includes isolating executing components such that multiple versions of a prerequisite component are permitted to co-exist. Isolation is implemented in various ways conventionally (e.g., Java class loaders, “.NET” assemblies), but its realization is seen to be heterogeneous and inconsistent when the software likely to be found on the user's machine is considered as a whole.
(A class loader, as described herein, refers to an object in the Java technology security model that is responsible for loading Java binary classes from a network into a local interpreter. A class loader keeps its classes in a separate namespace, so that loaded classes cannot interact with system classes and breach system security. “.NET” refers to a software technology available from Microsoft Corp. of Redmond, Wash. “.NET” provides network communication capabilities to applications during execution. A “.NET” assembly allows an application to access remote information.)
Therefore, there exists a need to overcome the problems discussed above, and, more particularly, a need to overcome the inefficiencies associated with deploying, updating and versioning software in a network system.